@noboz32 I sent you a PM

@bmarkus Thank you,I was thinking about it but was not sure.

@jcaron The Rising HF RHF301, on the frequencies described here: https://account.thethingsnetwork.org/api/v2/frequency-plans/US_902_928 So, it looks like that's 903900000 904100000 904300000 904500000 904700000 904900000 905100000 905300000 all on 125 kHz bw.

@jcaron oh thank you. I will do that. And I need a small help from you. In this code, I am trying to start my downlink once in a day. So I am using this code. import time a = time.localtime() hour = a.tm_hour minutes = a.tm_min if hour == 10 and minutes == 40: print('{0}:{1}'.format(hour, minutes)) But it's not working properly. Do I have to change some conditions ?

@robert-hh Sorry for the late and Thanks for your reply. I have tried with simple change like adding if statement with particular device address but it's not working. Is there any other possible way ?

@harish-kumar Well, you're not sleeping, so you shouldn't need to nvram_save/restore, but you're re-creating the LoRa object (twice!) in your loop, using two different modes (raw LoRa and LoRaWAN), and re-joining each time, so no wonder your frame counters get re-initialised. I'm really not sure you can use the current LoRa stack like this to achieve what you want. I'm quite certain it would require some extensive changes to the stack, especially if you really want to maintain true LoRaWAN compatibility (i.e. including ADR, MAC commands, etc.).

@robert-hh Thanks for your reply. Yeah exactly I am talking about repeater. Just let me know once they develop this part. Till then I will try to do by myself.

@harish-kumar said in To send data to cloud via lorawan instead of using wifi.: Hello everyone, I am using Lopy, I am new to this. I need to send some data to cloud via Lorawan instead of using wifi. Is it possible ? If it is , can anyone say me the procedures ? First check whether LoRaWAN is good for your application, it depends on the volume of data you are transmitting, what is the latency your application can accept, etc. Provide details. If it fits to your use case from networking view we can discuss how to implement.

@bed said in LoRaWAN FCnt size 16 or 32 bit?: @bmarkus The PyCom LoraWAN stack uses 32 bits for the uplink and downlink frame counters, even though only the bottom 16 bits are transmitted / received. Thanks!

@jcaron Thanks a lot , limiting the channels to 0-8 and 64 ( for join/accept) did the trick for now.

@jmarcelino OK, i contact the owner of the gateway to see if it's possible to connect to that gateway. Thanks for all informations! we can close the post ;)

@jmarcelino Thank you that appears to be correct! I get my push and pull acks now.

I know this is an old post but for me this is still an issue. Any may of learning more about the specifics would be very much appreciated e.g what does pycom.nvs_get(key) return? Should I see somthing in the REPL? Example: >>> lora.nvram_save() >>> l= pycom.nvs_get('lora') >>> print(l) None Am I going about this in completely the wrong way?

@livius Thank you so much!!! that's exactly what I needed

Hello bruno, this is what I did, instead of using the exemple code, I can set and catch the timeout error hence loop while not joint. while lora.has_joined() is not True: try: lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=20000, dr=0) except Exception as e: print('Not joined yet...')

@az311 OK thanks, that Payload Data is definitely from one of our examples (the ASCII codes spell "PKT # ..." ) so your node did join and is sending the data correctly. It's not a problem to see some "Not joined yet..." messages at the beginning - that's how it works - but they should stop once it joined. If you want to see what's happening you can add a message print("Connected!") on line 42 and then and a print("Sent") on 56

@150716t simpy connect to it by ftp and put file look here https://docs.pycom.io/chapter/toolsandfeatures/FTP.html

@neilh93 Great. Yes I use a similar thing for my commercial product. But remember that nodes may miss (due to RF issues, power) the "key change" message and still use the old one. What I did was to clone the existing device on the server backend but with the new keys. Then when a transmission arrives on the new device (which means the node has updated the keys) the old device is deleted. If the next transmission still arrives on the old device it means the node has not picked it up so a new key change message is scheduled for retransmission - this is repeated until it's finally picked up.